Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-151.txt

Text File | 1994-12-08 | 92.1 KB | 2,037 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 02 Aug 92       Volume 1 : Issue 151

Today's Topics:

    XWindows



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: XWindows
Date: 9 Jun 92 12:15:38 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> OK, I guess I need to justify why I personally think that distributed graphics
> are evil, even if handy in some instances. Imagine user Foo Bar, sitting by
> his/her computer, which suddenly starts acting sluggish. The end user will maybe
> reboot the machine, or try to shake it, or call the service technician.
>
> Little did they know that a client used CPU cycles over the net for nifty
> 3-D graphics that the manager needs for his multimedia presentation next
> Friday.

Kent brings up a very good point. It's the old multiuser fallacy all over
again--you know, supposedly being able to each user the illusion that they had
an entire machine all to themselves. In close to 30 years of development of
time-sharing systems, no one has ever managed to achieve this ideal; there's
no reason why they should stand any better chance now.

>
> It's fine to use such power for special projects, let's say "Industrial Light
> and Magic" style graphics shops. However distributed graphics computing is a
> little bit
> scary as a default setup for office computers. Most end users enjoy the
> snappiness
> of fast graphics, and they don't want anything happening behind their backs for
> decreasing the graphics performance. This is the reason multi-user UNIX systems
> never sell/perform well in the office environment (trust me, I looked with my
> left
> eye when sales reps tried to sell 'em).

Amen! In my view, the X Window system is just an attempt to perpetuate the
old multiuser model under a new guise, by keeping the control centre of the
application program on the central machine, instead of on my desktop where it
belongs.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.

+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Tue, 9 Jun 92 03:49:24 GMT


  If the Mac ran X Windows, you would be able to run *all* your
  applications via AppleTalk Remote Access. Sure, in the future we
  will all have mega-MIPS portables with roll-up high res displays,
  but until then being able to use a GUI from anywhere on the net
  without having to lug the computer around is pretty handy.

  I don't say this is as fast as having the application running on
  your own PC, or something you would do very often, but it is
  a capability worth having. For instance, with X Window apps I
  can show someone on a different machine the output from my program
  by just redirecting the display. No file sharing, Public Folders,
  or whatever required.

  Personally, I suspect that Apple are going to repeat the history
  of the Mac OS file system with distributed graphics. Right now we
  are getting the "who needs that sort of complexity" excuses that
  were used with the original, non-hierarchical, non-protected,
  non-networked Macintosh file system. After spending millions of
  dollars on "Research and Development", Apple now have a hierarchical
  file system with owner/group/other protection bits that can be
  mounted over a network. Gosh, how original :-) Why not save the
  time and money this time round by adopting X Windows?

    Hugh Fisher

+++++++++++++++++++++++++++

From: [e-mail] (Michael G. Reed)
Date: 9 Jun 92 12:21:12 GMT
Organization: Cornell National Supercomputer Facility

In article <[e-mail]>, [e-mail] (Hugh Fisher) writes:
|>
|>   If the Mac ran X Windows, you would be able to run *all* your
|>   applications via AppleTalk Remote Access. Sure, in the future we
|>   will all have mega-MIPS portables with roll-up high res displays,
|>   but until then being able to use a GUI from anywhere on the net
|>   without having to lug the computer around is pretty handy.
|>
|>   I don't say this is as fast as having the application running on
|>   your own PC, or something you would do very often, but it is
|>   a capability worth having. For instance, with X Window apps I
|>   can show someone on a different machine the output from my program
|>   by just redirecting the display. No file sharing, Public Folders,
|>   or whatever required.
|>
|>   Personally, I suspect that Apple are going to repeat the history
|>   of the Mac OS file system with distributed graphics. Right now we
|>   are getting the "who needs that sort of complexity" excuses that
|>   were used with the original, non-hierarchical, non-protected,
|>   non-networked Macintosh file system. After spending millions of
|>   dollars on "Research and Development", Apple now have a hierarchical
|>   file system with owner/group/other protection bits that can be
|>   mounted over a network. Gosh, how original :-) Why not save the
|>   time and money this time round by adopting X Windows?
|>
|>     Hugh Fisher

A number of very good points.  Having developed for both platforms in the
past (and continuing to do so now), I have to say I like my Mac better in
the sense that you have REAL LOCAL power (Q900), BUT you do not have the
'TRUE' power of X in thatif your machine has NO power (dumb, cheap, Xterminal
for example), you can run your applications anywhere and still get decent
performance.  If one machine on the net is slow, I can hop to another and
it makes no difference (especially with NFS crossmounting of filesystems).
The two systems are different, but it is only a matter of time before Apple
starts to move toward the X environment...I think you will DEFINITELY see
it with the new Powerstations...otherwise no one will take the machines
seriously.

- -Michael
- ---------------------------------------------------------------------------
Michael G. Reed                                ([e-mail])

Cornell National Supercomputer Facility      (Technology Integration Group)
Engineering And Theory Center, Room 747
Hoy Road                                              (607)/254-8806 [work]
Ithaca, New York 14853-3801  (USA)                    (607)/253-7962 [home]
- ---------------------------------------------------------------------------
DISCLAIMER: The views expressed above are not those of my employer.
- ---------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 9 Jun 92 20:44:31 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Hugh Fisher) writes:
>   Personally, I suspect that Apple are going to repeat the history
>   of the Mac OS file system with distributed graphics. Right now we
>   are getting the "who needs that sort of complexity" excuses that
>   were used with the original, non-hierarchical, non-protected,
>   non-networked Macintosh file system. After spending millions of
>   dollars on "Research and Development", Apple now have a hierarchical
>   file system with owner/group/other protection bits that can be
>   mounted over a network. Gosh, how original :-) Why not save the
>   time and money this time round by adopting X Windows?

OK, I repeat once again. The new graphics technology we showed at
WWDC didn't mention a word about networking. It does not state
that it may or may not happen, but it's not X Windows (bliss).
For X Windows users we have MacX.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Jun 92 06:46:20 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Hugh Fisher) writes:

>   If the Mac ran X Windows, you would be able to run *all* your
>   applications via AppleTalk Remote Access.

I can do that already, using Carbon Copy or Timbuktu. And I can do it
via a modem without the overhead of a networking protocol, with Timbuktu Remote.

>   Why not save the time and money this time round by adopting X Windows?

In my view, X Windows is a solution to the wrong problem. As far as I can
tell from the articles I've read on the subject, the main goal of the X Windows
designers was to come up with a device-independent, network-transparent
windowing system. They may have succeeded, but in the process, it seems to me
that they forgot that a windowing system was just a means to an end, and
they've given no thought to what that end was supposed to be.

So what was the original purpose of a windowing system? It was to make a
computer easier to use. The two direct contributions that a windowing system
makes to this (that I can currently think of :-)) are: a) modelessness
(switching windows is easier than switching job contexts within a single
terminal window) and b) direct manipulation.

X Windows certainly makes a contribution to the first goal, though as any
veteran Mac programmer knows, there's a lot more to modelessness than just
having multiple windows. But it helps not a whit with the second goal.

The whole point about a direct-manipulation interface is that you cease
thinking that you have to "tell the computer to do" something, and you
simply "do" it. Thus, the computer interface between you and your information
largely disappears, and requires little conscious thought to manage. To
achieve this you have to implement a lot of things, one of which is
*consistency* of behaviour. The Mac is legendary for this; the X Windows
people, on the other hand, seem fond of quoting the maxim "tools, not
rules" -- which seems about as far away from the idea of consistency as you
can get!

I also have techno-political objections to the client-server division in X
Windows: I think they got it backwards. In my view, a desktop machine is
the ultimate client. This means that the control centre for the applications
resides there, but all the actual grunt work gets done elsewhere. This
simultaneously makes the desktop machine perform very poorly as a server.
Instead, I envision a network full of file servers, database servers, compute
servers, even graphics rendering and compression/decompression servers!
But I think an "interface server" is a contradiction in terms: the nerve
centre of the application should physically reside as close to the
interface--and to the user--as possible--i e, on the desktop. This seems to
me the only reasonable way to maximize responsiveness, which is the essence of
a *personal* computing system.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 10 Jun 92 18:02:26 GMT
Organization: Lockheed Missiles and Space Co.

In article <[e-mail]> [e-mail]
(Lawrence D'Oliveiro, Waikato University) writes:

> In my view, X Windows is a solution to the wrong problem. As far as I can
> tell from the articles I've read on the subject, the main goal of the X
> Windows designers was to come up with a device-independent,
> network-transparent windowing system. They may have succeeded, but in the
> process, it seems to me that they forgot that a windowing system was just a
> means to an end, and they've given no thought to what that end was supposed
> to be.

> So what was the original purpose of a windowing system? It was to make a
> computer easier to use. The two direct contributions that a windowing
> system makes to this (that I can currently think of :-)) are: a)
> modelessness (switching windows is easier than switching job contexts
> within a single terminal window) and b) direct manipulation.

> X Windows certainly makes a contribution to the first goal, though as any
> veteran Mac programmer knows, there's a lot more to modelessness than just
> having multiple windows. But it helps not a whit with the second goal.

> The whole point about a direct-manipulation interface is that you cease
> thinking that you have to "tell the computer to do" something, and you
> simply "do" it. Thus, the computer interface between you and your
> information largely disappears, and requires little conscious thought to
> manage. To achieve this you have to implement a lot of things, one of which
> is *consistency* of behaviour. The Mac is legendary for this; the X Windows
> people, on the other hand, seem fond of quoting the maxim "tools, not
> rules" -- which seems about as far away from the idea of consistency as you
> can get!

This is probably the single largest misconception regarding X.  The fact
is, X explicitly and purposely provides "tools, not rules".  X provides a
device independent industry standard under which programmers can develop
portable graphics applications.  X provides a flexible set of graphics
primitives that do not dictate user interface style, but rather serve as a
layer upon which others may build.  X is not a GUI, but a platform upon
which GUI's (such as Motif and Open Look) may be built.  If there is a
complaint of a lack of consistency, this is the fault of the GUI in
question, not of X.  (It is often the fault of the programmer not following
the GUI's style guide, much like inconsistent Mac programs).  I consider
the fact that the user has a choice of GUI's a benefit, not a detriment,
much like a Unix user has a choice of shells.

BTW, having used and programmed the Mac for many years, I can attest to the
fact that the Mac's "consistency" was, for quite some time, more myth than
reality.  Some of the most popular programs violated Mac user interface
standards (anyone remember early versions of Microsoft Word?).  And, even
though it's gotten better over time, the Mac interface still has its share
of problems.  I won't cite examples, because I like the Mac and don't want
to start down that path.  Let's just say that part of the Mac's
"consistency" comes from the fact that it's had time to evolve, and some of
its problems stem from old baggage.

> I also have techno-political objections to the client-server division in X
> Windows: I think they got it backwards. In my view, a desktop machine is
> the ultimate client. This means that the control centre for the
> applications resides there, but all the actual grunt work gets done
> elsewhere. This simultaneously makes the desktop machine perform very
> poorly as a server.  Instead, I envision a network full of file servers,
> database servers, compute servers, even graphics rendering and
> compression/decompression servers!  But I think an "interface server" is a
> contradiction in terms: the nerve centre of the application should
> physically reside as close to the interface--and to the user--as
> possible--i e, on the desktop. This seems to me the only reasonable way to
> maximize responsiveness, which is the essence of a *personal* computing
> system.

The file server should reside close to the files (disks).  It should be
sized according to the file storage and access demands placed upon it.

The compute server should reside close to (i.e., run) the
computationally-intensive applications.  It should be sized according to
the computational requirements placed upon it.

The interface server should reside close to the user.  It should be sized
according to the demands of the individual user.  (Some people will not use
interactive 3-D graphics, etc).

The crux of the problem is bandwith.  How do you quickly move files from
your file server to your compute server?  How do you get results from your
compute server displayed on your interface server?  For low-power
applications, a Mac-type architecture, with file, compute, and interface
serversers in the same box on your desk is ideal.  But the Mac is not, and
never will be, a Cray (i.e., when the Mac performs like a Cray, the Cray
will perform like gangbusters).  Nor would giving everyone a Cray be an
effective allocation of resources, because very few users need a Cray all
of the time.  Yes, for a "personal" computing system, stick everything in
the desktop box.  (You can still use X, and your display, compute, and file
servers can reside in the same box and not suffer from network lag).  But
for a general computing system, you need X.

Network computing has taken system design past the desktop (or time-shared)
box.  To address the requirements of file storage, computational
capability, display capability, etc., one needs to size the components
appropriately AND ensure sufficient bandwith.  This may mean going to
faster hardware, reconfiguring the network, routing, clustering, etc.  In
the future, true distributed applications will run their crunching
component on the compute server and their interface component on their
interface server.  (But there will still be a bandwith requirement to pump
data between the computational and interface components).  In the meantime,
X presents a good solution to a difficult problem.

Unfortunately, one issue that I have not seen discussed is that of
portability.  It is not always possible (and, IMHO, rarely advisable) to
create "Mac-only" applications.  One of the beautiful aspects of X is that
it runs on everything from Macs to Crays.  As someone who has programs and
libraries resident on this range of devices, portability is a very
important consideration for me.  X gives me the display capability,
PostScript the hardcopy capability, and C and POSIX the "raw" programming
capability (I wish more systems currently followed POSIX.1 - fewer calls to
patch over).  There is a continuous trade-off between going with a
nonstandard state-of-the-art vs. an established standard.  For the
professional programmer, standards such as X are indispensible.
- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (John Kullmann)
Date: 10 Jun 92 21:47:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Hugh Fisher) writes:
>
>  If the Mac ran X Windows,

The Mac does run X Windows. It's a great product called MacX.


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 11 Jun 92 02:07:52 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
> I also have techno-political objections to the client-server division in X
> Windows: I think they got it backwards. In my view, a desktop machine is
> the ultimate client. This means that the control centre for the applications
> resides there, but all the actual grunt work gets done elsewhere. This
> simultaneously makes the desktop machine perform very poorly as a server.
> Instead, I envision a network full of file servers, database servers, compute
> servers, even graphics rendering and compression/decompression servers!
> But I think an "interface server" is a contradiction in terms: the nerve
> centre of the application should physically reside as close to the
> interface--and to the user--as possible--i e, on the desktop. This seems to
> me the only reasonable way to maximize responsiveness, which is the essence of
> a *personal* computing system.

This was the design idea behind Plan 9, and they also deliberately tried to
avoid X Windows, mostly because the overhead in association with this 'RISC
distributed OS' would have been far too much. They actually still have the
concept of distributed graphics (called 8 1/2 :-) , however the issue of
overhead
in forms of the protocol is of prime concern, and even if the their suite
of APIs don't cover all of the flashy X Windows protocols, they could do the
same
amount of work with 1/10 code size.

For more eye opening reading, fetch the Plan 9 papers from att.research.com.
These papers opened my eyes concerning compiler construction, and I would
predict that a similar RISC *) wave concerning OS and compiler construction will

happen during the later stage of the 90:ies.
- --
                                              Cheers, Kent

*) The same principle, let smaller component work together producing the end
result, instead of providing big fluffy modules.

+++++++++++++++++++++++++++

From: [e-mail] (Parag Patel)
Date: Thu, 11 Jun 92 18:58:48 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

They now have an X server that runs underneath their 8 1/2 windowing system,
or whatever they call its latest incarnation.  I think that it runs in
what MacX calls a "rooted" environment, and that it is quite fast.


    -- Parag

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 04:12:05 GMT

The real mistake the X people make is that they didn't police their levels.
In an ideal world, you'd buy an application that would make calls on a shared
library to put up windows, draw scroll bars, draw and track menus, buttons,\
etc. Since this would be a call to a shared library, if the user had a
"maclikelib" all their applications would draw mac style controls. If he
had a "motiflib", they'd all draw motif controls, similarly for openlook,
athena, hp, etc.  Rather like letting a user drop an extension into the
system folder that provides new CDEFs and MDEFs that override the look
and feel of the standard Mac controls and menus. (You've probably all seen
the extension that changes the scrollbar definition to give it two arrows
at eachg end.)

Unfortunately the X people botched it. They defined a uniform toolkit interface
called "Xt" for passing verbs and arguments to a control or menu, but they
never defined any standard sets of verbs and arguements. It would be like
apple never developing the standard apple event registry.  Sure, two entities
could talk to each other, but each entity speaks a different language.
Also, applications for X are generally sold so they _don't_ use dynamic
linked libraries to talk to their controls and menus. So, your word processor
will use the Athena widget set, your debugger the OpenLook widget set, and
your programmer's text editor will use the Motif set, and your window manager
will use something wierd the in-house programmer's cooked up. The poor user
must learn them _all_ (Left mouse button to scroll up, right mouse button
to scroll down. Oh No!, this is an Athena program, you have to Meta-Middle
click to scroll!)  It is agonizing. They did most of the job, but even with
the Mac to copy from, they botched it. It is now a hopeless mess.  And of
course, being unix, everything is protected from everything else, so you
can't override traps to fix other people's mistakes.  The problem is that Unix
began as a multi-user time sharing system, and the culture still doesn't
understand what it is for a computer to really work for a single user.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Sat, 13 Jun 1992 13:03:09 GMT

[e-mail] (Gary Henderson) writes:
>
>BTW, having used and programmed the Mac for many years, I can attest to the
>fact that the Mac's "consistency" was, for quite some time, more myth than
>reality.  Some of the most popular programs violated Mac user interface
>standards (anyone remember early versions of Microsoft Word?).

Early?

How about that new "drag'n'drop" capability, huh?  "Well, we tested it
both ways, and found that it made users 3.4% more productive..."
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Civil Rights:  1964 - 1992.  R.I.P.

+++++++++++++++++++++++++++

From: [e-mail] (Craig Struble {Toaster Strudel})
Organization: Gooey Green-Eyed Frogs
Date: Sun, 14 Jun 1992 18:53:02 GMT

In article <[e-mail]> [e-mail] (David Phillip Oster) writes:
>
>Unfortunately the X people botched it. They defined a uniform toolkit interface
>called "Xt" for passing verbs and arguments to a control or menu, but they
>never defined any standard sets of verbs and arguements. It would be like
>apple never developing the standard apple event registry.  Sure, two entities
>could talk to each other, but each entity speaks a different language.
>Also, applications for X are generally sold so they _don't_ use dynamic
>linked libraries to talk to their controls and menus. So, your word processor
>will use the Athena widget set, your debugger the OpenLook widget set, and
>your programmer's text editor will use the Motif set, and your window manager
>will use something wierd the in-house programmer's cooked up. The poor user
>must learn them _all_ (Left mouse button to scroll up, right mouse button
>to scroll down. Oh No!, this is an Athena program, you have to Meta-Middle
>click to scroll!)  It is agonizing. They did most of the job, but even with
>the Mac to copy from, they botched it. It is now a hopeless mess.  And of
>course, being unix, everything is protected from everything else, so you
>can't override traps to fix other people's mistakes.  The problem is that Unix
>began as a multi-user time sharing system, and the culture still doesn't
>understand what it is for a computer to really work for a single user.


I think the whole point of X has been lost somewhere in the translation. X
was started as a research project to produce a portable platform for producing
raster graphics. This has been achieved to a large extent. Soon the vendor
noticed that this was a good thing, so they began porting X to their machines,
and found it was extremely convienent for build graphical applications on
heterogeneous platforms.

X also includes the ability to run graphical applications across a network.
This was an important concept at the time of its initial design and
implementation. Personally, I find this ability quite a feature, and the
projects I've worked on have made use of this feature in an effective manner.

Granted, X needs a lot of work to meet the needs of a large portion of
personal users, but in a development environment, X has provided an excellent
way to share ideas, develop interface prototypes, and integrate networked
machines.

The point I feel that has been lost is that X is still an experiment. As with
a good portion of software developed at educational institutions, the
intended audience is not the general public, but researchers and developers.
X continues to be developed and refined, researching ideas in low bandwidth
graphics transfer, interface design, raster graphics technology, etc.

Xt, as part of the X distribution, is meant to allow interface researchers
and designers, to explore ideas in graphical user interface elements (widgets)
without restriction. Sure this can be a little ugly to end users, with
Open Look, Motif, Athena, Andrew, and many other widget sets running around
on their screen, but look at the possibilities. From this base, vendors can
produce computers to the general public with a clean consistent interface
that was based on a combination of ideas from these widget sets.

Of course, the threat of copyrights and patents threaten developers, by
making it difficult, if not impossible to take available ideas, and
incorporating them into a better generation of user interfaces. But this is
another discussion, that I'd rather delve into now.

X was not designed for the commercial market. It was designed for research
and development. Many of the complaints are valid if X is put into the
context of general public use, but if kept in the context of its original
goals, X has performed well up to expectations.
    See ya later,
- --
       IDEAL - Interface Design Environment and Analysis Lattice
Craig Struble                            | [e-mail]
Undergraduate Researcher                 | [e-mail]
Va. Tech HCI Project                     | [e-mail](SLIP)

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 15 Jun 92 03:58:30 GMT
Organization: Lockheed Missiles and Space Co.

In article <[e-mail]>
[e-mail] (Craig Struble {Toaster Strudel}) writes:

>I think the whole point of X has been lost somewhere in the translation. X
>was started as a research project to produce a portable platform for producing
>raster graphics. This has been achieved to a large extent. Soon the vendor
>noticed that this was a good thing, so they began porting X to their machines,
>and found it was extremely convienent for build graphical applications on
>heterogeneous platforms.

[miscellaneous other good points omitted]

>The point I feel that has been lost is that X is still an experiment. As with
>a good portion of software developed at educational institutions, the
>intended audience is not the general public, but researchers and developers.
>X continues to be developed and refined, researching ideas in low bandwidth
>graphics transfer, interface design, raster graphics technology, etc.
.
.
.
>X was not designed for the commercial market. It was designed for research
>and development. Many of the complaints are valid if X is put into the
>context of general public use, but if kept in the context of its original
>goals, X has performed well up to expectations.

While I think that X is a Good Thing, and agree with many of Mr. Struble's
points, I must disagree with "X is still an experiment."  While X may have
begun as part of Project Athena, it has certainly become a commercial
standard and must be viewed in that context.

Incidentally, there was an interesting article a while ago (in Digital
Review, I believe) regarding how various computer vendors attempted
to make X a commercial standard for networked graphics in order to
prevent Sun's NEWS system from becoming the same sort of de-facto
standard that NFS had become.  As I recall, the "experts" quoted in the
article agreed that this may have caused X to be standardized upon
somewhat prematurely.
- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (John Coolidge)
Organization: A/UX Enabling Technologies - OS Group, Apple Computer, Inc.
Date: Mon, 15 Jun 1992 16:39:54 GMT

[e-mail] (Craig Struble {Toaster Strudel}) writes:
>I think the whole point of X has been lost somewhere in the translation. X
>was started as a research project to produce a portable platform for producing
>raster graphics. This has been achieved to a large extent. [...]
>X also includes the ability to run graphical applications across a network.
>This was an important concept at the time of its initial design and
>implementation. Personally, I find this ability quite a feature, and the
>projects I've worked on have made use of this feature in an effective manner.

The problem is that no one ever did a 'lessons learned' review of X,
took out the good parts, and then started over from scratch. This is
(seriously!) one of the most important parts of a well-designed research
program. The other problem is that they took 'mechanisms not policy' too
far. By claiming that all they were doing was building a platform for
putting bits on screens, they not only sidestepped the issue of what
sort of interface to use (appropriate for a research project which
wanted to support multiple interfaces) but also the issue of how these
interfaces would interact with the rest of the system.

>The point I feel that has been lost is that X is still an experiment. As with
>a good portion of software developed at educational institutions, the
>intended audience is not the general public, but researchers and developers.

It depends. While that might still be the 'party line' from the X
Consortium office (although I doubt even they would claim this now), it
certain isn't reality. I'm going to be part of the staff at the Apple
booth at Xhibition this week (Thursday 10-2, Friday 1-4). There will be
hundreds of vendors and thousands of people, just about all of which
are pitching or buying X as a commercial-grade windowing system
(usually with Motif or Open Look on top). If you told all of them that
they were buying and selling an experimental system, I think they'd
either laugh or run away (from the software, not you :-)).

- --John

        so you found a girl who thinks really deep thoughts;
        what's so amazing about really deep thoughts?
                -- Tori Amos, "Silent All These Years", _Little_Earthquakes_

+++John L. [e-mail]+++++++++++++++++++++++
I speak for myself, not for Apple Computer. Copyright 1992 John L. Coolidge.
Copying allowed only if attributed, and if all copies may be further copied.

+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Mon, 15 Jun 92 23:45:51 GMT


  I don't think X Windows 11 was ever intended as just a research
  project, unless you consider the entire MIT computing environment
  as one. No doubt it could use some revision and improvement, but
  then what piece of software couldn't? As for the "mechanisms, not
  policy" approach, remember that the original designers didn't even
  have a consistent graphical API to use. For those who work with
  multiple hardware platforms, X is a tremendous step forward even
  if the GUIs are not all there yet.

  As for commercial GUIs, Apple perhaps missed an opportunity here.
  Suppose, back in 1987/88 Apple had offered to sell the Macintosh
  Desktop interface as an X Windows Toolkit. I think it would have
  blown Open Look and Motif away.

  Getting back to an Apple-specific issue, I'd still like to see
  Quickdraw and the Event Manager "lifted up" and running on top
  of the X Protocol (not the Xlib API). As I said before, this
  would make *all* your applications usable through AppleTalk
  Remote Access, and the people who develop Timbuktu Remote, Carbon
  Copy, etc wouldn't have to spend all their time reinventing the
  code.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 16 Jun 92 16:43:47 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>,
[e-mail] (Hugh Fisher) writes:

>   Getting back to an Apple-specific issue, I'd still like to see
>   Quickdraw and the Event Manager "lifted up" and running on top
>   of the X Protocol (not the Xlib API). As I said before, this
>   would make *all* your applications usable through AppleTalk
>   Remote Access, and the people who develop Timbuktu Remote, Carbon
>   Copy, etc wouldn't have to spend all their time reinventing the
>   code.

Timbuktu and Carbon Copy run on top of the AppleTalk protocol stack, so they
should work over AppleTalk Remote Access just fine. Do you have any information
to the contrary?

The only things these programs have to "reinvent" are clever ways of minimizing
the amount of information that has to be transmitted to keep two displays in
sync, while minimizing the delay in updating when a change occurs. It may be an
interesting problem, but I'm *glad* that they couldn't dictate restrictions on
the design of QuickDraw that could have made their task easier.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.

+++++++++++++++++++++++++++

From: [e-mail] (Eric Dittman)
Date: 16 Jun 92 04:37:23 GMT
Organization: Texas Instruments Component Test Facility

Has anyone ported xview to A/UX?
- --
Eric Dittman                  Texas Instruments - Component Test Facility
[e-mail]    [phone]
Disclaimer:  Not even my opinions.  I found them by the side of the road.

+++++++++++++++++++++++++++

From: [e-mail] (Kris Hampel)
Date: 16 Jun 92 12:45:06 GMT
Organization: Physics, Imperial College, London

In article <[e-mail]> Kent Sandvik <[e-mail]> writes
>For X Windows users we have MacX.

Yes - but do you keep it up to date and fully fledged? e.g. macX 1.1 (and
I guess 1.1.7) are X11.3 1/2, do not do sensible authentication (either
a dialogue box for every window or no security) and the three buton mouse
emulation is poor.

Basically unless I absolutely have to use x-windows for graphics, I stick
with telnet or use a faster machine with a better x-windows server (a
decstation of all things, grumble, grumble).

Nb - this isn't a flame, more a wish for an easier life...

Kris Hampel

Solid State Theory Group, Blackett Laboratory.
==========> kris @ sst.ph.ic.ac.uk <==========

+++++++++++++++++++++++++++

From: [e-mail] (Chris King)
Organization: Island Graphics Corp.
Date: Wed, 17 Jun 1992 00:22:16 GMT

[e-mail] (Gary Henderson) writes:

> Lots of stuff about X tools not rules deleted.

>This is probably the single largest misconception regarding X.  The fact
>is, X explicitly and purposely provides "tools, not rules".  X provides a
>device independent industry standard under which programmers can develop
>portable graphics applications.  X provides a flexible set of graphics
>primitives...........

The graphics primatives that X provides are *really* primative.  The
graphics capabilities Apple will be providing with QuickDraw GX will
be light years ahead of anything that X provides. A big chunk of
Apple's market is in the Graphics Arts. X is useless for this. Things
like advanced typographic support is absolutly mandatory. There is no
provision for this in the X specification. Besides, I have yet to see
a reasonably bug free X implementation that doesn't require hours of
hacking around to figure out a reasonable environment.


                    Chris King
                    Island Graphics Corp.
                    San Rafael Ca.
                    [e-mail]





+++++++++++++++++++++++++++

From: [e-mail] (Thomas Deweese)
Organization: Eastman Kodak Co., Rochester, NY
Date: Wed, 17 Jun 92 13:19:48 GMT


>graphics capabilities Apple will be providing with QuickDraw GX will
                            ^^^^^^^^^^^^
>be light years ahead of anything that X provides. A big chunk of
>Apple's market is in the Graphics Arts. X is useless for this. Things

  I thought I was fairly up to date on Apple developments, but I have not heard
a peep about this QuickDraw GX.  What is it?  When will it be released/
offically announced.  Where can I get a look at it?

>                    Chris King
>                    Island Graphics Corp.
>                    San Rafael Ca.
>                    [e-mail]

                        Thomas DeWeese
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 17 Jun 92 15:59:16 GMT
Organization: Lockheed Missiles and Space Co.

In article <chris.708740536@midway> [e-mail] (Chris King) writes:

>The graphics primatives that X provides are *really* primative.  The
>graphics capabilities Apple will be providing with QuickDraw GX will
>be light years ahead of anything that X provides.

As I believe I said, "There is a continuous trade-off between going with
a nonstandard state-of-the-art vs. an established standard."  Also, is
QuickDraw GX (still in the "will be" stage, BTW), going to be ported
to other platforms?  Is it going to address the issue of network
computing, so its graphics can be linked to real computing power?

>A big chunk of Apple's market is in the Graphics Arts. X is useless for
>this. Things like advanced typographic support is absolutly mandatory.
>There is no provision for this in the X specification.

Again, X was designed to be a general solution to the problem of
standard, portable, device independent graphics.  However, to maintain
the ability to address specific requirements, X was designed to be
extensible.  A common extension on many implementations (including the
one that I use at work) is Display PostScript, which almost certainly
provides the capabilies that you need (I believe your Island Graphics
products can produce PostScript output, but I could be mistaken).
Although I haven't seen QuickDraw GX, I know the current QuickDraw
cannot match PostScript's typographic support, and I doubt that GX will
be any better at giving you a true display-to-hardcopy match than
Display PostScript will.

Although Display PostScript is not part of X, it is often implemented as
an extension to it.  This extension demonstrates X's flexibility and
extensibility, it is available on multiple vendors' platforms, and the
computers that it runs on are much faster than Macs.  Furthermore, using
Display PostScript under X allows the programmer to use much of the same
code for display and hardcopy graphics.
- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 20 Jun 1992 22:25:39 +0200
Organization: University of Karlsruhe, FRG

In comp.unix.aux, article <[e-mail]>,
  [e-mail] (Gary Henderson) writes:
< In article <chris.708740536@midway> [e-mail] (Chris King) writes:
<
< >The graphics primatives that X provides are *really* primative.  The
< >graphics capabilities Apple will be providing with QuickDraw GX will
< >be light years ahead of anything that X provides.
<
< As I believe I said, "There is a continuous trade-off between going with
< a nonstandard state-of-the-art vs. an established standard."  Also, is
< QuickDraw GX (still in the "will be" stage, BTW), going to be ported
< to other platforms?  Is it going to address the issue of network
< computing, so its graphics can be linked to real computing power?
<
Quickdraw GX is written in a high-level language (in other words, C).
Apple probably is thinking about licensing that code.

< Although I haven't seen QuickDraw GX, I know the current QuickDraw
< cannot match PostScript's typographic support, and I doubt that GX will
< be any better at giving you a true display-to-hardcopy match than
< Display PostScript will.
<
Just as Postscript currently can't match the typographic support of Quickdraw
GX -- things like parameterized fonts (you want the font only semi-bold? Or
want a 120-point font looking loke a typographic big font, not just like a
blown-up 12 point font? It seems that GX can do that -- the font supplier
must provide for it of course) or like treating the boundaries of a thick
free-form curve as an object unto itself or like doing some very interesting
picture editing (there were some demos at the WWDC...).

< Although Display PostScript is not part of X, it is often implemented as
< an extension to it.  This extension demonstrates X's flexibility and
< extensibility, it is available on multiple vendors' platforms, and the
< computers that it runs on are much faster than Macs.  Furthermore, using
< Display PostScript under X allows the programmer to use much of the same
< code for display and hardcopy graphics.

You can use the same code to control Quickdraw GX-based windows and printers
also, so that's not really an argument except that GX isn't released yet. ;-)

NB: I don't know how easy it would be to write a Postscript interpreter
    to control a plotter or other vector-based device. GX will be able to do
    that too.

- --
And on the seventh day, He exited from append mode.
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Organization: Lockheed Missiles and Space Co.
Date: Sun, 21 Jun 92 06:08:12 GMT

In article <[e-mail]> [e-mail] (Matthias Urlichs) writes:
>In comp.unix.aux, article <[e-mail]>,
>  [e-mail] (Gary Henderson) writes:

>< ... I said, "There is a continuous trade-off between going with
>< a nonstandard state-of-the-art vs. an established standard."  Also, is
>< QuickDraw GX (still in the "will be" stage, BTW), going to be ported
>< to other platforms?  Is it going to address the issue of network
>< computing, so its graphics can be linked to real computing power?

> Quickdraw GX is written in a high-level language (in other words, C).
> Apple probably is thinking about licensing that code.

Not Object Pascal? ;) But seriously, Apple has a less than stellar
record w.r.t. "opening" their code.  Also, networking still hasn't been
addressed, so it's just an upgrade of the same proprietary non-networked
solution bound to the slow Mac host.

>< Although I haven't seen QuickDraw GX, I know the current QuickDraw
>< cannot match PostScript's typographic support, and I doubt that GX will
>< be any better at giving you a true display-to-hardcopy match than
>< Display PostScript will.

>Just as Postscript currently can't match the typographic support of Quickdraw
>GX -- things like parameterized fonts (you want the font only semi-bold? Or
>want a 120-point font looking loke a typographic big font, not just like a
>blown-up 12 point font? It seems that GX can do that -- the font supplier
>must provide for it of course) or like treating the boundaries of a thick
>free-form curve as an object unto itself or like doing some very interesting
>picture editing (there were some demos at the WWDC...).

This is beginning to sound like a broken record... will be, may do, etc.
Multiple master fonts give fluid variation between boldnesses and
widths.  As for the other, well perhaps you can change a 12 point
block-text font into a 120 point display font with the same name, but if
they look completely different, what's the point?  That's what the
different font families are for.  I prefer knowing what the font looks
like before I use it.

I do not doubt that doubt that Apple has learned from their mistakes,
but how much?  I still need portability.  I still need to write graphics
code that runs on workstations and mainframes.  To meet the needs of the
general computing community, Apple should provide added value only after
they provide support for standards.  Quickdraw GX should come after X.
(I also think that Apple, as an OSF member, should provide Motif as
well, but I'll probably catch a lot of flack for that.)  Innovation is
nice, but satisfy the basics first.  Maybe we could write a "Maslow's
Heirarchy of Needs" for computer programmers.

>< ... Display PostScript under X allows the programmer to use much of
>< the same code for display and hardcopy graphics.

>You can use the same code to control Quickdraw GX-based windows and printers
>also, so that's not really an argument except that GX isn't released yet. ;-)

That's what they said about TrueType.  I could fit all of the TrueType
printers I've seen in a thimble.  Instead of increasing their support
for PostScript, they continue with their old "NIH" attitude.  More
proprietary extensions in lieu of, rather than in addition to,
standards.

Really, I like Macs.  Apple tries to make my life as a user easier.  I
just wish they'd try to do the same for my life as a programmer.  I
resent their trying to lock me into their platform.  I always considered
that IBM's way, and I never cared much for it.  If not for A/UX, my next
computer would not be a Mac.  It's actually kind of funny... Apple
provides me with "added value" for free, but forces me to pay extra for
standards.  Hopefully just a vestige of their NIH mentality that will
dissolve over time.



Summary:  Support the standards, then add proprietary value.  Don't
necessarily restrict a system to a "lowest common denominator", but meet
it before you try to surpass it.




This will be my last posting on this subject.

:)  :-)  8v)  :)
:-)  8v)  :)  :-)
8v)  :)  :-)  8v)
:-)  8v)  :)  :-)
(Many delighted netters)

I made the mistake of getting involved in a local Unix-vs-VMS flame war,
and it occupied far too much of my time.  Anyone who has not discovered
the need for standards will not see the light via my feeble debating
skills.  They will learn for themselves when they are forced to move to
the next OS, or the next shell, or the next graphics library, or the
next whatever.  Modularize and re-use code, isolate nonstandard
portions, keep them to a minimum.

Best wishes to all patient readers.
- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 22 Jun 92 16:08:39 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Gary Henderson) writes:

> But seriously, Apple has a less than stellar
> record w.r.t. "opening" their code.  Also, networking still hasn't been
> addressed, so it's just an upgrade of the same proprietary non-networked
> solution bound to the slow Mac host.

Networking is a completely separate issue that has nothing to do with the
graphical model, regardless of what X Windows enthusiasts may believe. It's
really very simple: graphics has to do with presenting information in a
visual form, while networking has to do with moving information from one
place to another without stringing up wires between every possible pair of
places. Quite different problems, really.

[things that QuickDraw GX will apparently be able to do deleted]
> This is beginning to sound like a broken record... will be, may do, etc.

I agree. All these neat claims about GX will gain a lot more credibility
once it becomes a real product.

> That's what they said about TrueType.  I could fit all of the TrueType
> printers I've seen in a thimble.

What about the several *hundred* different models of printer for which you
can get Mac printer drivers? *All* of them work with TrueType fonts--including
the PostScript ones.

Must be a large thimble. Either that or you're looking in the wrong aisle...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
First of all, the lightning strike was a message from God to get rid of
thin Ethernet.             -- Art King, letter in Computerworld June 8.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 25 Jun 92 03:51:00 GMT
Organization: Secret Society of Software Mungers

In article <[e-mail]>,
[e-mail] (Gary Henderson) writes:
> Although Display PostScript is not part of X, it is often implemented as
> an extension to it.  This extension demonstrates X's flexibility and
> extensibility, it is available on multiple vendors' platforms, and the
> computers that it runs on are much faster than Macs.  Furthermore, using
> Display PostScript under X allows the programmer to use much of the same
> code for display and hardcopy graphics.

Eh? So now we have both Postscript, and X, and level 1 and 2 of Postscript,
and Display Postscript, and XR12, R13, R14, R15...

Aren't standards wonderful, you just need to keep track of 'em.

Once again, I personally agree with Bill Joy about X Windows :-).

Kent

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 25 Jun 92 15:30:20 GMT
Organization: Lockheed Missiles and Space Co.

I know I said "This will be my last posting on this subject..."   I lied.
This AppleSpeak could not go unchecked.

In article <[e-mail]> [e-mail]
(Kent Sandvik (High Priest of SSSM)) writes:

>So now we have both Postscript, and X, and level 1 and 2 of Postscript,
>and Display Postscript, and XR12, R13, R14, R15...

Distinguishing between X11 R3, R4, R5, and future versions is no more
justified than doing the same with different Mac software releases (hmmm
- - MFS, HFS, QuickDraw, color QuickDraw, and soon-to-be-released
QuickDraw GX).  And, unlike some software, X has increased capability
AND SPEED with later releases.

As you probably already know, PostScript Level 2 is a new release that
brings together previous extensions of PostScript and Display PostScript
- - much like one would attempt to incorporate all of their extensions to
an OS in a new release.  Seems to me like a company planning to UNBUNDLE
extensions could learn from this.

Standards evolve.  One of the ways in which this process occurs is when
vendors support standards and then add value.  Free market forces
determine which "added value" products are worthwhile.  Other vendors
add the product, often licensing it from the original source (see: X,
PostScript, NFS).  Eventually, the added value becomes standard.

>Once again, I personally agree with Bill Joy about X Windows :-).

Oh, then I suppose that in Apple's neverending quest to support
standards, they were going to support NEWS as an industry standard?
Funny, but I don't remember any statements to that effect.  Apple
management just sat back and hoped that the confusion would last.
When confusion exists, vendors of nonstandard systems stand a better
chance of taking advantage of their customers.

>Aren't standards wonderful, you just need to keep track of 'em.

Start.
ANSI C.  POSIX.  X.  PostScript.  Motif (Apple *is* an OSF member).


It often appears to me that Apple considers it in their best interest
to add to any confusion that may exist regarding standards.  It is a
crime that a company with such technical ability is being run by
lawyers and MBAs.  I would bet that, given budget, Apple's programmers
could layer an X API over your existing API in a matter of months.


- ------------------------

Computer vendors should support the standards, then add value.

- ------------------------


- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (John Coolidge)
Date: 25 Jun 92 18:33:16 GMT
Organization: A/UX Enabling Technologies - OS Group, Apple Computer, Inc.

[e-mail] (Gary Henderson) writes:
>Standards evolve.  One of the ways in which this process occurs is when
>vendors support standards and then add value.  Free market forces
>determine which "added value" products are worthwhile.  Other vendors
>add the product, often licensing it from the original source (see: X,
>PostScript, NFS).  Eventually, the added value becomes standard.

Unfortunately, often the 'added value' is not (valuable, that is). X
wouldn't be a bad standard if it was redesigned from scratch with most
of the 'value' thrown out and real value (like a standard way of doing
GUI layers so that things like MOOLIT were easy to do). Display
PostScript wouldn't be a bad standard if it had actually been designed
for real-time display applications instead of being slow and piggy (or:
why does my Q700 - or my fx or my IIci for that matter - display SO much
faster than a NeXTStation Turbo with a faster processor?).

X is ok for some things. One of these isn't fast graphics response. Can
you imagine anything close to QuickTime under X? On a 16MhZ 68030? With
both client and server running on the same box? It's annoying that idraw
running on a SparcStation 2 performs about as well as MacDraw on an SE.
It's telling that there are virtually no arcade-style games for X (even
QuickDraw is slow for games; X is right out).

>>Aren't standards wonderful, you just need to keep track of 'em.

>Start.
>ANSI C.

Check. A/UX Developer Tools 1.1.

>POSIX.

Check.

>X.

Check.

>PostScript.

Check.

>Motif (Apple *is* an OSF member).

Available from ICS. Four out of five ain't bad.

>It often appears to me that Apple considers it in their best interest
>to add to any confusion that may exist regarding standards.

It often appears to me that the hype over 'standards' is often a
marketing checkbox thing and not related to productivity. Does anyone
think that Display PostScript or X is really well suited to the
Macintosh, given that the Mac is 1) designed to run on slow (68000, slow
68030) processors, 2) designed to provide a feeling of responsiveness,
3) designed around the notion of 'one person, one computer'? Why?

Also, it seems to me a bit silly to complain that Apple has willfully
ignored the 'standards' in not adopting either X or DPS. Both of these
emerged years after QuickDraw was fully announced, documented, and
implemented. It seems to me that it would be much more fair to complain
to the X Consortium and Adobe for their failure to adopt the QuickDraw
standard when designing their added value graphics systems. Or is Apple
somehow the only vendor required to follow existing standards (and those
before they even exist), while others are perfectly justified in
ignoring Apple's work?

- --John

        We did Windows applications, but we didn't inhale.
               -- Borland CEO Phillipe Kahn, discussing his firm's
                  support for OS/2 2.0

+++John L. [e-mail]+++++++++++++++++++++++
I speak for myself, not for Apple Computer. Copyright 1992 John L. Coolidge.
Copying allowed only if attributed, and if all copies may be further copied.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 25 Jun 1992 17:25:05 GMT

[e-mail] (Gary Henderson) writes:
>I know I said "This will be my last posting on this subject..."   I lied.
>This AppleSpeak could not go unchecked.

Kent was not speaking for Apple.  If you disagree with him, don't drag
Apple into the fray.

>[e-mail] (Kent Sandvik (High Priest of SSSM)) writes:
>
>>So now we have both Postscript, and X, and level 1 and 2 of Postscript,
>>and Display Postscript, and XR12, R13, R14, R15...
>
>Distinguishing between X11 R3, R4, R5, and future versions is no more
>justified than doing the same with different Mac software releases (hmmm
>- MFS, HFS, QuickDraw, color QuickDraw, and soon-to-be-released
>QuickDraw GX).  And, unlike some software, X has increased capability
>AND SPEED with later releases.

Unlike which software, please?  I hope you weren't implying Apple,
because you just listed the improvements in the sentence before.

(And you left out QuickerDraw, by the way.  Not to mention 32-Bit
QuickDraw's three versions.  Maybe that's because each has been
perfectly backward compatible with the previous ones, so that Apple has
been able to bundle them into new systems without your noticing?)

>Computer vendors should support the standards, then add value.

Vendors should deliver what their customers want.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Never piss off a computer.

+++++++++++++++++++++++++++

From: [e-mail] (Richard Deal)
Date: 25 Jun 92 19:30:09 GMT
Organization: Naval Research Labs (Washington DC)

In article <[e-mail]> [e-mail] writes:
>
>X is ok for some things. One of these isn't fast graphics response. Can
>you imagine anything close to QuickTime under X? On a 16MhZ 68030? With
>both client and server running on the same box? It's annoying that idraw
>running on a SparcStation 2 performs about as well as MacDraw on an SE.
>It's telling that there are virtually no arcade-style games for X (even
>QuickDraw is slow for games; X is right out).
no arcade like games for X .... I agree with you on alot of what you are
talking about here but look around a little.  (Xtank, Xcheck, asm, Xsol,
Xtrek, xmj ...)
These are networking arcade games some use a server model some are
distributed.  The lack of responce time in X programs usually come from
por-use of toolkits.  Xtank and asm use a server model and can be relitively
zippy on a SPARC 2 with around 8 players in the arena.
>
>It often appears to me that the hype over 'standards' is often a
>marketing checkbox thing and not related to productivity. Does anyone
>think that Display PostScript or X is really well suited to the
>Macintosh, given that the Mac is 1) designed to run on slow (68000, slow
>68030) processors, 2) designed to provide a feeling of responsiveness,
>3) designed around the notion of 'one person, one computer'? Why?
>
X11r4 is was very responsive on my MacII under A/UX 2.01.  It is also
some what responsive on sun 3/50 here at work.  X11 is not all that
cpu intensive.  I does lend itself nicely to full motion as well.  I
have forgotten the name of the program but I have seen an X gif
movie viewer that would put Quick time to shame.  The movie files
did take up some space as they were in gif format.
    What is the use of this notion of one person, one computer.
I like as many as I can get my hands on myself.  I also seem to
remember hearing something about apples working with radius on
distributed networks (on networked cpu's and rockets).
I am not sure what X was first designed on but some of its first
ports were to sun 2's and 3's, and macII's among others.


- --
#include <std/*>
The Butcher
Butch Deal                   [e-mail]
- --------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 25 Jun 92 22:59:27 GMT
Organization: Lockheed Missiles and Space Co.

In article <[e-mail]>
[e-mail] (Jamie R. McCarthy) replies to my
[[e-mail] (Gary Henderson)] rantings
regarding [e-mail] (Kent Sandvik (High Priest of SSSM))'s article:

>me:
>>I know I said "This will be my last posting on this subject..."   I lied.
>>This AppleSpeak could not go unchecked.

Jamie:
>Kent was not speaking for Apple.  If you disagree with him, don't drag
>Apple into the fray.

Ah.  I accused him of indulging in AppleSpeak.  Not quite the same thing.
Anyone can do it, but the misinterpretation is understandable.

Kent:
>>>So now we have both Postscript, and X, and level 1 and 2 of Postscript,
>>>and Display Postscript, and XR12, R13, R14, R15...

Me:
>>Distinguishing between X11 R3, R4, R5, and future versions is no more
>>justified than doing the same with different Mac software releases (hmmm
>>- MFS, HFS, QuickDraw, color QuickDraw, and soon-to-be-released
>>QuickDraw GX).  And, unlike some software, X has increased capability
>>AND SPEED with later releases.

Jamie:
>Unlike which software, please?  I hope you weren't implying Apple,
>because you just listed the improvements in the sentence before.

I know *many* individuals who have complained about S7's speed in
comparison to S6.  Before I get toasted in the flames, I *know* that it's
system software vs. "just a graphics engine", but you asked.

Jamie:
>(And you left out QuickerDraw, by the way.  Not to mention 32-Bit
>QuickDraw's three versions.  Maybe that's because each has been
>perfectly backward compatible with the previous ones, so that Apple has
>been able to bundle them into new systems without your noticing?)

No, I was going to mention QuickDraw's other revs, but I thought that
would be splitting hairs.  Apple has done very few things to/for me
that I haven't noticed.  I *tried* to stay on top of things through
Volume V...  It seems like there's so much to keep up with -
"the problem with standards is that there are so many of them" -
but I think it's important to do so.


>>Computer vendors should support the standards, then add value.

>Vendors should deliver what their customers want.

Enough customers seem to want standards, so


- --------------

Computer vendors should support the standards, then add value.

- --------------

Is there an echo in here?

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Fri, 26 Jun 92 03:09:58 GMT

In article <[e-mail]>, [e-mail] (John Coolidge) writes:
  ..stuff deleted..
|>
|> >It often appears to me that Apple considers it in their best interest
|> >to add to any confusion that may exist regarding standards.
|>
|> It often appears to me that the hype over 'standards' is often a
|> marketing checkbox thing and not related to productivity. Does anyone
|> think that Display PostScript or X is really well suited to the
|> Macintosh, given that the Mac is 1) designed to run on slow (68000, slow
|> 68030) processors, 2) designed to provide a feeling of responsiveness,
|> 3) designed around the notion of 'one person, one computer'? Why?
|>
|> Also, it seems to me a bit silly to complain that Apple has willfully
|> ignored the 'standards' in not adopting either X or DPS. Both of these
|> emerged years after QuickDraw was fully announced, documented, and
|> implemented. It seems to me that it would be much more fair to complain
|> to the X Consortium and Adobe for their failure to adopt the QuickDraw
|> standard when designing their added value graphics systems. Or is Apple
|> somehow the only vendor required to follow existing standards (and those
|> before they even exist), while others are perfectly justified in
|> ignoring Apple's work?
|>
|> --John
|>
|> +++John L. [e-mail]+++++++++++++++++++++++
|> I speak for myself, not for Apple Computer. Copyright 1992 John L. Coolidge.
|> Copying allowed only if attributed, and if all copies may be further copied.


   Apple IS an X Consortium member. Possibly the Consortium did not adopt
   the announced, documented, and implemented Classic Quickdraw standard
   because a certain laywer-happy organisation never offered it to them.
   Sun, IBM, Dec, Adobe, etc have all donated software, time, and code to
   the various X releases. What have Apple done?

   Notice that I say Classic Quickdraw: X11R3 came out before or about the
   same time as the official release of the Mac II and Color Quickdraw.
   Color Quickdraw had some interesting problems, such as the non-support
   for 32 bit displays, and serious hassles with offscreen images and pixel
   values. These had to be fixed up later in 32 bit Quickdraw, while X11
   has supported 32 bit color from the start.

   As for productivity, standards are not all hype. As a Mac programmer
   I've put many hours into learning the API. Where this is important
   stuff, like the menu manager, I don't mind. But there are far too
   many differences just apparently for the sake of being different, such
   as NewPtr instead of malloc or FSRead(file, count, pointer) instead
   of read(file, pointer, count). This is "adding value"? It is not just
   programmers who have to go through this either, judging by the recent
   postings about TrueType.

   As a user, I object to the fact that the price of my Macintosh (and
   indirectly, that of applications) has been jacked up with the extra
   money spend on "R&D" that is in fact reinventing the wheel. As a
   programmer, I object to having to invest time and effort in learning
   a slightly different way to provide the same functionality. And now
   that Windows is selling in millions of copies, and X is the standard
   for Unix boxes, I don't have to put up with it anymore.

    Hugh Fisher

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 26 Jun 92 18:23:11 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>,
[e-mail] (Hugh Fisher) writes (among other things):

>    Notice that I say Classic Quickdraw: X11R3 came out before or about the
>    same time as the official release of the Mac II and Color Quickdraw.
>    Color Quickdraw had some interesting problems, such as the non-support
>    for 32 bit displays, and serious hassles with offscreen images and pixel
>    values. These had to be fixed up later in 32 bit Quickdraw, while X11
>    has supported 32 bit color from the start.

This works both ways. From the beginning, the colour-capable Macs have
included a Palette Manager which lets multiwindow, multitasking applications
share colour-table displays without totally wrecking each other's colours.
This feature is still important today: not all of us can yet afford true-colour
direct-RGB displays, though an LC with 512K of VRAM and the 12-inch screen
(32,768 simultaneous colours) is a step in the right direction.

This is just a repeat of a point I made before--Apple has spent, and is
continuing to spend, a lot of effort on adding value to the low end. For some
reason this idea is getting less and less popular with other vendors...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Fri, 26 Jun 1992 05:53:37 GMT

In article <[e-mail]> [e-mail] (Hugh Fisher) writes:
_>   Notice that I say Classic Quickdraw: X11R3 came out before or about the
_>   same time as the official release of the Mac II and Color Quickdraw.
_>   Color Quickdraw had some interesting problems, such as the non-support
_>   for 32 bit displays, and serious hassles with offscreen images and pixel
_>   values. These had to be fixed up later in 32 bit Quickdraw, while X11
_>   has supported 32 bit color from the start.
I notice you carefully refrain from saying that X11R3 also had serious hassles
with offscreen images and pixel values. In fact the Sun implementation of it
that I had the misfortune to be forced to use didn't implement offscreen images
at all.

+++++++++++++++++++++++++++

From: [e-mail] (John Coolidge)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 26 Jun 1992 17:45:02 GMT

[e-mail] (Gary Henderson) writes:
>In article <[e-mail]>
>>>Computer vendors should support the standards, then add value.
>>Vendors should deliver what their customers want.
>Enough customers seem to want standards, so
>--------------
>Computer vendors should support the standards, then add value.
>--------------

I think this is the crux of the discussion. What constitutes 'enough'
customers to warrant putting the engineering resources into following a
standard? If Apple were to layer QuickDraw on top of X (a non-trivial
task, given that the two graphics models are very different in many
places), how many more boxes would they sell? My personal guess is 'very
few'; X is largely a UNIX-world connectivity issue, and Apple supports X
in that arena (MIT X server and MacX). To make a convincing case, you'd
have to show that non-UNIX-based customers (the vast bulk of sales) care
about X windows support.

Remember that standards are domain-specific. The 80x86, E/ISA, S/VGA,
etc. PC architecture is a 'standard'. Should Apple dump the 680x0 (and
PowerPC) and build 80x86 boxes with 'added value' in order to support
the standards. DOS is a standard, as is Windows3. Should Apple drop the
Mac GUI and API in order to support the standards? What about S100? That
was a standard for many years -- should we have just kept extending it?
How about CP/M? the 6502 or Z80? VM/CMS?

The point is that standards are important because 1) they 'add value' or
2) they allow interoperability. Apple seems to have decided thus far
that putting QuickDraw/QD GX on top of X would not add value (in fact, I
suspect it would decrease value markedly -- if you thought Sys7 was
slow, try Sys8 with an X layer). On the interoperability front, Apple
offers X server support under both A/UX and the MacOS, and at least two
third-partices offer MacOS-as-a-client support (slow, I might add; don't
try playing OIDS under X :-)).

- --John

        The line between pleasure and pain
        Can't be measured by means of the brain
        Mere reason alone can never explain
        How the heart behaves
                -- Was (Not Was), "How The Heart Behaves", _Are_You_O.K.?_

+++John L. [e-mail]+++++++++++++++++++++++
I speak for myself, not for Apple Computer. Copyright 1992 John L. Coolidge.
Copying allowed only if attributed, and if all copies may be further copied.

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Organization: Lockheed Missiles and Space Co.
Date: Fri, 26 Jun 92 16:39:30 GMT


I wrote:
>> Standards evolve.  One of the ways in which this process occurs is when
>> vendors support standards and then add value.  Free market forces
>> determine which "added value" products are worthwhile.  Other vendors
>> add the product, often licensing it from the original source (see: X,
>> PostScript, NFS).  Eventually, the added value becomes standard.

John responds:
> Unfortunately, often the 'added value' is not (valuable, that is).

Free market forces are supposed to eliminate this.  Admittedly, the world
is not perfect.  Consumers are often not well informed.  IMHO, backward-
compatiblilty should be handled through emulation more often, with more
"fresh starts".  Then again, I'm not the one who has to do it.

John also states:
> X wouldn't be a bad standard if it was redesigned from scratch with most
> of the 'value' thrown out and real value (like a standard way of doing
> GUI layers so that things like MOOLIT were easy to do).

Considering its rapid ascendancy as a standard, X obviously filled a
serious need that was not being addressed in an acceptable manner.
Networked graphics are very important in engineering, where most
workstations have been sold.  The same can be said of a multiplatform
standard.  Saying "Apple could have done better" is pointless.  They
didn't.

I would agree that many institutions would change things given the
opportunity of "going back and starting over".  There might have
been a higher-level layer with an endorsed "look and feel".
(IMHO, Sun is the only organization currently standing in the way
of this.)  Who knows, Apple might re-think their decision not to take
part in the OSF/Motif RFT process.


John says:
> Display PostScript wouldn't be a bad standard if it had actually been
> designed for real-time display applications instead of being slow and
> piggy.

I would like to see DPS supported so programs didn't require as much
re-writing during a port.  Also, for simple 2-D output, it would be
very helpful to use the same code for display and hardcopy.  DPS does
not animate well, even on my RS/6000.  But for *basic* graphics
(charts, graphs, etc.), even Ghostscript on my X terminal is more than
sufficent (let's say that the time required to display the data is
less than 5% of the time required to absorb the information).


> X is ok for some things. One of these isn't fast graphics response. Can
> you imagine anything close to QuickTime under X?

I have seen real-time video (basically, TV in an X window) on
workstations at MIT.  Mot Media-Lab stuff, either - these were
student-accessible devices in an Athena cluster.  I believe the client
and server for this app were running on the same box.  It was *high*
quality video (screen resolution, probably about 500 x 500 pixel
windows).


I realize that ANSI C, POSIX, X, PostScript are all supported under
A/UX.  No arguments.  I just find it somewhat amusing that standards &
"added value" are reversed.  I understand that in the case of the Mac,
it's pretty much a personal computer (I won't use the verboten "PC")
that's stretched into a workstation.  I just feel that A/UX is treated
like a b*stard child.  I had to drive 30 miles just to order A/UX from
someone who I could scream at face-to-face if something went wrong (my
other choice was a telemarketer).  And I can already tell that the
people on the net like you and Jim (and the many others) provide
*much* more help over the net than the vendor will out of his
storefront.  They are (for the most part, anyway) computer salespeople
with some Unix training, not real Unix users or programmers.



I said:
>> It often appears to me that Apple considers it in their best interest
>> to add to any confusion that may exist regarding standards.

John replies:
> It often appears to me that the hype over 'standards' is often a
> marketing checkbox thing and not related to productivity. Does anyone
> think that Display PostScript or X is really well suited to the
> Macintosh, given that the Mac is 1) designed to run on slow (68000, slow
> 68030) processors, 2) designed to provide a feeling of responsiveness,
> 3) designed around the notion of 'one person, one computer'? Why?

The "hype" over standards enables nearly identical code to be run on
multiple platforms.  This is important to users/programmers who are
responsible for writing code for these platforms.  We have major
applications that can be ported from DEC to IBM to Cray to Convex in
(transfer time + compile time + qa routine runtime) * (num machines).

W.R.T emulation speed, Apple doesn't seem to have a problem promoting
slow 3-rd party DOS emulators.  ("Why your next DOS computer should be
a Macintosh").


John adds:
> Also, it seems to me a bit silly to complain that Apple has willfully
> ignored the 'standards' in not adopting either X or DPS. Both of these
> emerged years after QuickDraw was fully announced, documented, and
> implemented...

The way things usually work, sometimes unfortunately for the
trailblazers, is: some company comes out first with a proprietary
product to perform a task.  Later, other competing systems evolve.  A
standard develops when either multiple vendors independently choose
one of the products (X), a customer with sufficient power (U.S. gov't)
dictates that "Any system purchased by us must meet this
specification".  (Or, I suppose, when an official standards group like
ANSI says it is).  A company can improve the position of its product
by agreeing to license it to other vendors (NFS) - this is probably
what Apple should have done.  Saying that "the newer technology
should mimic the older technology" is like saying "the first product
out the door is the standard, and everyone should follow it".
Simply stated, I disagree.

- -----------------

One point that may have been lost in my last couple of postings:
Regardless of my strong desire for support for standards, the Mac is a
fine as personal computer, and A/UX makes a fine addition.  Apple
deserves credit for their work done in and popularization of
interactive graphics and GUI's, as well as their system and network
concepts which allow "plug & play" components with very little
customization effort on the part of the user.  Whether or not one
chooses to consider the MacOS & QuickDraw a "standard", Apple has "set
the standard" in many of these areas.


I'll try to shut up for real now.  Any bets?

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail]
Date: 27 Jun 92 01:06:35 GMT
Organization: Amherst College, Amherst Mass.

In article <[e-mail]>, [e-mail] (Hugh Fisher) writes:
> In article <[e-mail]>, [e-mail] (John Coolidge) writes:
>   ..stuff deleted..
>    a slightly different way to provide the same functionality. And now
>    that Windows is selling in millions of copies, and X is the standard
>    for Unix boxes, I don't have to put up with it anymore.

I'd probably agree with you a couple of points, but I can't let this
one go by. If you've got complaints about the Mac being a) slow and
b) difficult/nonstandard to program, DON'T GET EXCITED BECAUSE THERE ARE
MILLIONS OF COPIES OF WINDOWS OUT THERE. Windows has got to be the most
hideous, painful and criminal excuse for a graphical environment I have
ever seen. Leaving my distaste for its presentation aside, I have watched
Windows bring "middle of the road" PC's to their knees, and make big bad
'486-based systems act like someone poured molasses into their cooling
slots. While I'm not big fan of the infamous "Ingram report", it's
absolutely true that a cheap-o Mac will outperform a PC-clone costing
twice as much if you make it run Windows.

And Windows is no joy to program, either. One of my co-workers spent
a good number of years making a living writing code for all sorts of
machines and operating systems. He is one of the most stoic, reserved
men I have ever met. After 6 months of Windows programming, he was
LITERALLY tearing his hear out and beating his fist on his desk.

At least with UNIX you get something worthwhile: speed.

- -Craig Garnett
Amherst College

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 22 Jun 92 00:24:39 GMT
Organization: Secret Society of Software Mungers

In article <[e-mail]>, [e-mail] (David
Phillip Oster) writes:
> The problem is that Unix
> began as a multi-user time sharing system, and the culture still doesn't
> understand what it is for a computer to really work for a single user.

Amen!

Kent

+++++++++++++++++++++++++++

From: [e-mail] (Maynard J. Handley)
Organization: Cornell-Materials-Science-Center
Date: Sat, 27 Jun 1992 14:17:02 GMT

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>,
>[e-mail] (Hugh Fisher) writes (among other things):
>
>>    Notice that I say Classic Quickdraw: X11R3 came out before or about
>the
>>    same time as the official release of the Mac II and Color Quickdraw.
>>    Color Quickdraw had some interesting problems, such as the
>non-support
>>    for 32 bit displays, and serious hassles with offscreen images and
>pixel
>>    values. These had to be fixed up later in 32 bit Quickdraw, while
>X11
>>    has supported 32 bit color from the start.
>
>This works both ways. From the beginning, the colour-capable Macs have
>included a Palette Manager which lets multiwindow, multitasking
>applications
>share colour-table displays without totally wrecking each other's
>colours.
>This feature is still important today: not all of us can yet afford
>true-colour
>direct-RGB displays, though an LC with 512K of VRAM and the 12-inch
>screen
>(32,768 simultaneous colours) is a step in the right direction.
>
>This is just a repeat of a point I made before--Apple has spent, and is
>continuing to spend, a lot of effort on adding value to the low end. For
>some
>reason this idea is getting less and less popular with other vendors...

I'd like to amplify this point. Have any of you people raving about X tried
to actually program in it, or use it for decent graphics work? There are a
number of major problems with X and color. The first is no gamma correction
in the system. This means that the same image is wildly different colors on
different machines- eg display a gif on an RS6000 monitor or a SUN monitor
and see what I mean. Or try to create a color ramp for subtle shading- a
linear function won't work. I had to putz around with a cubic to get it to
work, and I have to change the parameters of the cubic for each different
monitor on which I wish to run my code.

And what does this "X has always had 32 bit color" mean? Huh? Do you mean
by that "While color quickdraw has always supported writing to an abstract
color space that the system will render as best it can on the screen, X
will only work properly on a 32 (ie 24 bit) display" ? I have yet to see a
workstation with a 24 bit screen on it, so what matters for practical
purposes is how X deals with 8 bit displays, and the way it deals with them
sucks. When you need lots of colors, the only wy to get them is to screw up
every other image on the screen. There seem no facilities for pallette
animation (if there are, they are so baroque I've yet to see a program that
uses them.)

X supports network graphics. That is good. And it is the ONLY good thing
that can be said about it. From this crazy idea of trying to implement
object oriented programming in C rather than using C++, to the fact that
there STILL does not exist a motif toolkit without bugs, to the insane
amounts of disk and RAM space the system takes up, I've not been too
impressed by it.

Maynard Handley

+++++++++++++++++++++++++++

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Mon, 29 Jun 1992 01:45:20 GMT

In article <[e-mail]> Hugh Fisher,
[e-mail] writes:
>   As for productivity, standards are not all hype. As a Mac programmer
>   I've put many hours into learning the API. Where this is important
>   stuff, like the menu manager, I don't mind. But there are far too
>   many differences just apparently for the sake of being different, such
>   as NewPtr instead of malloc or FSRead(file, count, pointer) instead
>   of read(file, pointer, count). This is "adding value"?

As a Macintosh Pascal programmer I take objection to this C-centricity.
Don't try and impose your language's conventions on the system.  If you
want this sort of naming similarity you should use your language's
libraries.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 29 Jun 92 02:06:06 GMT
Organization: Secret Society of Software Mungers

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
> In article <[e-mail]>,
[e-mail] (Gary Henderson) writes:
>
> > But seriously, Apple has a less than stellar
> > record w.r.t. "opening" their code.  Also, networking still hasn't been
> > addressed, so it's just an upgrade of the same proprietary non-networked
> > solution bound to the slow Mac host.
>
> Networking is a completely separate issue that has nothing to do with the
> graphical model, regardless of what X Windows enthusiasts may believe. It's
> really very simple: graphics has to do with presenting information in a
> visual form, while networking has to do with moving information from one
> place to another without stringing up wires between every possible pair of
> places. Quite different problems, really.

Yes, and when the GX specs are out there we could do more serious discussion
than this 'I don't know but it stinks' style of argumentation. Sorry, I can't
state too much about an unannounced product, but I'm sure most of us will
know the story behind GX when the specs are finally official.

As for standards, I was a big standards bigot 4 years ago, UNIX and networking.
Sadly I've seen the dangers with standards, for instance read the latest USENIX
Login magazine, one half of the magazine is reserved for tracking evolving
IEEE standards concerning UNIX. Should most of our engineers track and fix
bugs related to standards, or create innovative products that will create bigger
markets for everyone? The choice is ours.

Cheers,
Kent
PS: The best standards just appear automatically. The worst appear when
certain institutions want to kill other companies. Remember NeWS vs. X.

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Organization: Visix Software Inc., Reston, VA
Date: Mon, 29 Jun 92 00:32:54 GMT

[e-mail] (Gary Henderson) writes:
> Enough customers seem to want standards, so
> --------------
> Computer vendors should support the standards, then add value.
> --------------
> Is there an echo in here?

No, just a misunderstanding of standards.  Customers want what they think
standards will give them.  The problem is that standards (at least as they
exist in the current computer industry) do not actually give them these
benefits.  The Macintosh is a much better-designed system overall (i.e.,
including both hardware and software) than any "standards-based" system out
there, bar none.  I've even sat on standards committees myself--I know what
I'm talking about...

If you want to build a great piece of software, you don't pick a UNIX
workstation running X and Motif--you pick the Mac, because it doesn't get in
your way, and actually helps you with many things.

Personally, I think that anyone who wants to force vendors to support things
like X and Motif should first be required to actually write 50,000 lines or
more of code using them.  The glamour wears off *real* fast.


Amanda Walker                        [e-mail]
Visix Software Inc.                     [phone]
- --
"You're making the same mistake that I did--assuming people are capable of
 figuring out obvious behavior, when in practice they're not" --Eric Wiseblatt

+++++++++++++++++++++++++++

From: [e-mail] (John Bruner)
Date: 29 Jun 92 13:24:37 GMT
Organization: CSRD, University of Illinois

Kent Sandvik writes:
>
> David Phillip Oster writes:
>> The problem is that Unix
>> began as a multi-user time sharing system, and the culture still doesn't
>> understand what it is for a computer to really work for a single user.
>
>  Amen!

The problem with people flaming Unix is that they haven't taken the
time to research the allegations that they toss out.

The first version of Unix *WAS NOT* a timesharing system.  Early
sources (such as the classic CACM paper by Thompson and Ritchie)
indicate that it was a reaction to the growing complexity of MULTICS.
Thompson found a little-used PDP-7 and coded a small operating system.
Apparently it was a very good vehicle indeed for a graphical space war
game.
- --
(Dr.) John Bruner, Deputy Director            [e-mail]
Center for Supercomputing Research & Development    [phone] (voice)
University of Illinois at Urbana-Champaign        [phone] (FAX)
305 Talbot Laboratory; 104 South Wright St.; Urbana, IL  61801

+++++++++++++++++++++++++++

From: [e-mail] (CT Shock)
Organization: University of Maryland at College Park
Date: Tue, 30 Jun 1992 13:18:16 GMT

In article <[e-mail]> [e-mail] (John Bruner) writes:
>Kent Sandvik writes:
>>
>> David Phillip Oster writes:
>>> The problem is that Unix
>>> began as a multi-user time sharing system, and the culture still doesn't
>>> understand what it is for a computer to really work for a single user.
>>
>>  Amen!
>
>The problem with people flaming Unix is that they haven't taken the
>time to research the allegations that they toss out.
>
>The first version of Unix *WAS NOT* a timesharing system.  Early
>sources (such as the classic CACM paper by Thompson and Ritchie)
>indicate that it was a reaction to the growing complexity of MULTICS.
>Thompson found a little-used PDP-7 and coded a small operating system.
>Apparently it was a very good vehicle indeed for a graphical space war
>game.
>--

Amen to that. Having used MULTICS on a Honeywell 6000 (back in the dark ages)
I'll take UNIX _any_ day. Lord of the Rings my ass....

    -Todd


---------------------------

End of C.S.M.P. Digest
**********************